In the telecommunications industry, primary or inter-exchange telecommunication services carrier, e.g., MCI Communications Corp., provide many services for customers. One type of service MCI provides includes the provision of long-distance communication or "carrier" services supporting communication of, e.g., audio (telephone) or data information, over their telecommunications networks. "Resellers", as known in the industry, refer to companies that resell the services of the primary telecommunication services carrier (MCI). There are generally two types of resellers, alternatively referred to herein as "carrier customers": 1) switchless resellers who sell telecommunications services to their customers and then use the networks of other carriers for all of their customers' traffic and, 2) facility-based resellers who are carriers having their own switch networks, yet use the primary telecommunications services carrier, e.g., MCI, to carry overflow traffic, as a backup network, or to extend carrier services beyond their limited geographical coverage.
The carrier customers of the inter-exchange carrier (e.g., MCI) are typically provided with a portfolio of services that include, inter alia, the entry and processing of orders for its carrier customers.
Generally, the entering and processing of carrier customer orders proceeds as follows: First, the carrier customer, or reseller, compiles a list of its new Automatic Number Identifiers "ANI" orders or, a list of ANIs for deactivation. The reseller submits these ANIs to the inter-exchange carrier (MCI) they intend to use to carry traffic for these ANIs and additionally submits the new ANI orders to the Local Exchange Carrier ("LEC") responsible for each ANI. These orders are also known as Preferred Interexchange Carrier ("PIC") orders, as they are used to implement a new PIC for each ANI at the LEC switch, a process which is known as LEC provisioning. The LEC then completes the PIC order by pointing the selected ANI to the Carrier Identification Code ("CIC") of the selected inter-exchange carrier. This is done at the LEC switch that serves the access line for that ANI. The LEC then sends a confirmation back to the reseller. Thus, when a long-distance call is originated from that ANI, the LEC switch will route the call to the selected inter-exchange carrier's network. The inter-exchange carrier will transport the call, but instead of billing the caller directly, the inter-exchange carrier bills the reseller. The reseller is responsible for billing the caller.
In an alternative embodiment, a reseller may perform its own LEC provisioning by supplying the LEC ith the reseller's customer's ANIs and the PIC for each ANI. However, the reseller must still submit ANI orders to their selected inter-exchange carrier, so that the inter-exchange carrier can update its systems to know how to bill calls for those ANIs.
Other processes, for example, deactivating a reseller's customer's ANI, are additionally performed using the same systems infrastructure.
Along with order entry and processing, the carrier must also provide order reporting for their reseller customers. For example, when the LEC returns a confirmation that a PIC order was completed, the inter-exchange carrier needs to report this status update to the reseller. The reseller also needs to know which ANI orders were not successfully completed.
The inter-exchange carrier MCI provides the order entry, processing, and reporting functions for its carrier customers via a Carrier Network Services ("CNS") system such as illustrated in the block diagram of FIG. 1.
Specifically, the prior art CNS system 10 illustrated in FIG. 1 contains the following functional elements:
An Order Service Center ("OSC") 20 for receiving the compiled list of the carrier customer's new ANI orders or, a list of ANIs for deactivation. Typically, these orders are shipped to the OSC 20 via E-mail, fax, NDM, or by mailing a diskette.
A Carrier Base 30 for receiving the list of orders through a GUI for immediate downloading to a server (not shown) for eventual storage in a database (not shown). The Carrier Base 30 performs a validating function, i.e., validates the ANIs against a Calling Area Database ("CADB") 35 which is an application on a mainframe computer which stores all valid ANIs in the North American Numbering Plan, along with the calling area and LEC for each ANI.
A Reseller Enhanced LEC Interface ("RELI") block 40 is also an application residing on a mainframe computer which receives a file of new orders, e.g.,via IBM's Network Data Mover ("NDM") over a WAN, and provides a systems interface between the inter-exchange carrier's systems infrastructure and that of an LEC, indicated as block 45 in FIG. 1. Orders for ANI activations and deactivations are sent to the LECs via the RELI system either by NDM or by other means such as by "QUICKPIC" which is a system described and claimed in co-pending U.S. patent application Ser. No. 08/923,872 entitled "System and Method for Real-Time Exchange of Customer Data Between Telecommunications Companies" and filed on Sep. 2, 1997, now issued to U.S. Pat No. 5,898,795 on Apr. 27, 1999 and assigned to the same assignee as the present invention, that provides a real-time interface between RELI and the LECS. The contents and disclosure of cop-ending U.S. patent application Ser. No. 08/923,872 now issued to U.S. Pat No. 5,898,795 on Apr. 27, 1999 and is incorporated by reference as if fully set forth herein.
An OCIS application block 50 which is an application residing on an IBM mainframe computer and functions as MCI's order entry system for all customer accounts. In OCIS, a reseller's new ANI is entered as a 10xxx ANI designating that the ANI is not subscribed to MCI for long-distance, but can reach MCI's network via the standard 10xxx dial-around method, or, in the case of reseller's ANIs, via a carrier identification code translation at the LEC. MCI's carrier customers (resellers) have their own and ANI install orders are routed to the LEC along with the reseller's CIC. The LEC must perform a translation from the reseller's CIC to MCI's CIC for each long-distance call, based on the ANI or access line, to ensure the call gets routed to MCI's network. Designating resellers ANIs as 10xxx ANIs in OCIS allows the reseller to own and manage their customer base.
In the architecture of FIG. 1, the Carrier Base server 30 has an IP messaging interface to the OCIS 50 which receives a front-end reject report, i.e., an IP message (over a WAN), for each ANI that cannot be validated against CADB or that fails field edits which are applied by the Carrier Base 30. In response, the OCIS application block 50 adds or cancels an ANI and responds to Carrier Base Server 30 with messages confirming which ANI orders were successfully completed and which ones were rejected. The RELI block 40 also creates an unmatched transaction file for ANIs which have not been installed in OCIS and sends to Carrier Base 30, e.g., via NDM, a daily file containing the status of all ANI orders. Besides acting as a front end to an OCIS application 50 and a RELI application 40, the Carrier Base 30 serves as a mid-range based server process and database for status information from OCIS 50 and RELI 40.
The Netcap functional block 60 is an MSV application residing on a mainframe computer which is an order entry system for enhanced calling features, e.g., features for Virtual Private Network ("VPN") calling plans. Features for VPN calling plans are manually entered into Netcap application 60 while customer account data, including ANIs, are automatically fed to the Netcap application 60 from OCIS 50. The preferred inter-exchange carrier, for example, typically provides a VPN service, e.g., MCI's "VNET", under which reseller services are managed and billed. Feature data, such as VPN routing translations and range privileges, are fed from Netcap block 60 to a Service Control Manager ("SCM") block 70 which distributes this data to a plurality of Data Access Points ("DAPs") indicated as elements 75 that perform call processing on VPN, 800/900 numbers, and other types of calls for network switches 85.
The Automatic ANI Download System ("AADS") block 80 receives ANIs for activation from OCIS block 60, and updates each of the switches in the carrier's network with newly received ANIs, so that the switches 85 can receive and process calls from these ANIs.
The current implementation of the prior art CNS system 10 has several limitations. First, a service agent in the OSC 20 must manually extract the customer's ANIs from the e-mail, fax, disk file, or whatever means is used, and enter these ANIs into the Carrier Base GUI 30. If an ANI fails a field edit, the customer is not made aware of this until after they have sent the ANI to the OCIS application 50.
Additionally, some of the PIC orders fail at the LEC and can not be provisioned. Additionally, incorrect or invalid ANI's are installed in the carrier's On-line Customer Information System 50.
Furthermore, reports provided by Carrier Base are limited in functionality as they have to be delivered via mail, e-mail, fax, or other non-real-time means. Thus, a failed ANI could not be reported until after the PIC order had been sent to the LEC and a confirmation was received back from the LEC.
It would be highly desirable to provide an order processing and reporting system for carrier customers that obviates the limitations of the prior art can be more efficiently validated, stored and tracked for subsequent remote customer access, and can be successfully installed at an LEC prior to LEC provisioning.